Whenever two computer modules or two computer systems communicate with each other, miscommunication is a real possibility. The formats used by each computer for file names, data, commands and other quantities of interest may differ markedly. The range and/or data type of alphanumeric variables or logical variables exchanged, used or processed by each computer may be inconsistent with each other. The number of arguments requested by one computer module or system (the "consumer") and provided by the other computer module or system (the "producer") may not agree. These are a few of the many inconsistencies that may prevent the modules or systems from communicating with each other. Further, if one, or both, of the communicants is replaced by a new, enhanced or merely updated version, miscommunication may be an unwelcome byproduct of the new arrangement. If the two communicating computers or modules are designed and assembled by different companies, or even by different divisions of a single company, the problem of communication is even more complex.
Two computer modules or systems (referred to here as computer "subsystems" for convenience) normally communicate (exchange data, commands, control signals, etc.) by means of an interface that, in theory, provides a translation between the internal environments of the two subsystems. The interface may be constructed as part of one or the other of the subsystems or may be a separate entity that receives and translates commands, control signals and/or data from each subsystem into commands, control signals and/or data usable by the other subsystem. Where two subsystems work cooperatively on a common task, the interface plays a critical role. Because of this, it is important to provide an approach for evaluating the implementation of the interface, for monitoring the proper functioning of the interface, and for testing the valid use of the interface. Attributes, such as the number of data arguments, the data types and ranges of the arguments, and the formats required for command, or control signals, should be checked for compatibility and consistency when a consumer subsystem calls for data or other information from a producer subsystem.
With the passage of time, an interface may require changes, due to addition of new functionality, removal of unneeded or inconsistent functionality, performance enhancements, fixing of bugs and many other natural developments in the evolution of a computer subsystem. When the interface, or consumer or producer, changes but the interface can still provide communication between the consumer and the producer, the present interface is said to be "compatible." Otherwise, the interface is said to be "incompatible," and further changes may be required for continued communication. Compatibility allows an older version of software in one computer subsystem to work with a newer version of software in a communicating subsystem, without recoding or recompiling, and is thus desirable.
Other workers have provided interface features that enhance the role of the interface. Yanes, in U.S. Pat. No. 5,202,998, discloses a multiprocessor system in which each processor has an associated interface circuit and register for a status flag. Each interface circuit receives update messages from other interface circuits from time to time, and corresponding flag bits are changed, using an algorithm that does not require these status changes to follow a predetermined protocol or be recognized in a particular order.
A testing system that determines the health or operational status of a computer system is disclosed in U.S. Pat. No. 5,210,757, issued to Barlow et al. The computer system performs a short, high priority sequence of operations that require use of a bus interface. The testing system compares the results of this sequence with corresponding ideal results to determine if use of this bus interface has any effect on the computer system being tested. The computer system is determined to be operational, non-operational or of questionable operability, depending upon comparison of the real and ideal results.
U.S. Pat. No. 5,265,243, issued to Povenmire et al, discloses a flexible, all-purpose interface controller that provides an interface between a central processor and each of a plurality of peripheral I/O devices. The interface controller contains arrays of NAND gates and NOR gates that can be configured differently for each different peripheral device, and is especially useful in ASIC applications.
Friedrich et al disclose an interface for a dynamically reconfigurable computer system tester, useful for modeling and testing different processes performed by the computer, in U.S. Pat. No. 5,276,877. The computer system is configured for and performs a selected process, using selected input parameters, and certain output parameters or metrics are examined to evaluate computer performance for this process.
A computer subsystem communication system, including a bus and bus interface for each subsystem, is disclosed by Boasson in U.S. Pat. No. 5,301,339. Relying on the interactions of the bus interfaces, each subsystem may call for and receive specified information of a particular data type, without specifying the particular subsystem in which the specified information of specified data type is found.
Pio-di-Savoia et al disclose a generator of auto-checking testing functions for a software interface in U.S. Pat. Nos. 5,357,452 and 5,359,546. Where proper behavior of the software interface can be adequately described by its formal specification (semantic expressions, pre- and post-execution conditions), a testing function is automatically generated and used to evaluate the interface and to identify any exceptions for normal execution.
U.S. Pat. No. 5,379,386, issued to Swarts et al, discloses a microchannel interface controller in integrated circuit form that controls, but does not do substantial testing on, high speed transfer of data and control signals between a Micro Channel bus, a local processor and a dedicated local bus in a master-slave environment. Testing is primarily concerned with error detection and reporting.
Sheth et al disclose an I/O Module interface for multiple computers attached to a dual system bus in U.S. Pat. No. 5,386,517. This interface provides a means of communication and data/control signal transfer with a sub-requestor bus that connects a plurality of sub-requestor modules, usually computer peripherals, each with its own data protocols and clock rates. This IO Module interface tailors or translates the data and control signals so that the main host and processors are not burdened with these overhead tasks. When a sub-requestor module or a main host processor changes, a new I/O Module interface would apparently be required.
A platform for performing off-station verification and integration of an Automatic Test Program Generation test program is disclosed in U.S. Pat. No. 5,390,194, issued to Mannle. This platform oversees initial integration of a test program, including simulation of a selected set of situations on a plurality of digital circuit boards to be tested. Continued use of this platform to monitor and test interface operation after the initial testing is not disclosed.
In U.S. Pat. No. 5,392,209, Eason et al disclose an interface system for providing a data interface between a plurality of biological testing instruments and a central database. The system includes a master rules file for analyzing the format and type of test data that are presented. The system can integrate test data that are received in fragments. If a new test instrument is added, or if an old test instrument is changed substantially, it appear that a new interface system would be provided.
Barrington et al, in U.S. Pat. No. 5,394,540, disclose a network testing system that includes network simulator and a message processor that intercepts and examines messages between a tested network component and other network components. An intercepted message is selectively changed or deleted and its effect on network operation is observed. An interface, located between the tested component and the remainder of the network, controls the message processor and simulator.
A test mode readback system for a memory display interface is disclosed by Hoffert et al in U.S. Pat. No. 5,404,318. A selected sequence of test pixel color values, test paths for pixel processing and test modes are stored and applied to test the memory display and interface, by reading out and comparing the pixel output values produced the sequence of input commands. No compatibility testing is disclosed where a display unit configuration is changed.
U.S. Pat. No. 5,404,428, issued to Wu, discloses a computer graphics interface system for updating derived items in a view model that includes multiple coordinate systems. The interface system implements display of an acyclic graph in each of a plurality of selected coordinate systems to determine whether each of a selected group of derived item is valid, or whether one or more of these items is not valid, for each of the coordinate systems. The validity test appears to relate to the derived items, not to functioning of the interface itself.
Jessen et al disclose an interpreter for performing remote testing of a computer system, in U.S. Pat. No. 5,410,681. A first or host computer system, working from a script, issues a sequence of commands to a second or target computer system that emulates user activity on the target system. Responses and status of the target system and status of the host-target interface are monitored as each of the host system commands is issued. Compatibility of different combinations of available hardware and software is also tested.
Most of these approaches test the proper operation of a computer subsystem on one side or the other of an interface, not the proper functioning of the interface itself, nor the response of the interface to a fundamental change in the subsystem. Many of these approaches work from a predefined script of exercises that may not address all issues of interoperability of two computer subsystems. What is needed is a testing system that can be used together with an interface and its associated subsystems to evaluate functioning of the interface for interoperability, compatibility and consistency, when a subsystem served by the interface is changed fundamentally, by introduction of a new version, by substantial enhancement of the subsystem, or in some equivalent manner. Preferably, this testing system should provide both standard testing features and reconfigurable testing features for special purpose testing and monitoring.